The solution according to one or more embodiments of the present invention relates to the data processing field. More specifically, this solution relates to the de-serialization of objects based on differences in information content.
Exchange of data among different software components is a commonplace activity in modern data processing systems. For this purpose, serialization/de-serialization techniques (also known as deflating/inflating techniques) may be used.
Particularly, a source object to be provided from a source software component to a target software component is serialized by converting it into a corresponding representation that may be passed to the target software component. The representation of the source object is then de-serialized by creating a target object in the target software component that maps it (i.e., it is semantically equivalent to the source object). Typically, the representation of the source object is in a format that is independent of the actual implementation of both the source object and the target object; in this way, it is possible to exchange data among heterogeneous software components (especially in data processing systems with distributed architecture) in a reliable manner.
In this context, however, a problem arises when the source software component and the target software component are written in different programming languages that do not support the same types of objects (for example, classes with fields of different types in object-oriented programming languages). Indeed, in this case it may be possible that no type of the target software component perfectly matches the representation of the source object. Therefore, it is quite difficult (if not impossible) to de-serialize the representation of the source object into the corresponding target object automatically.
A typical example is the exchange of objects between a Rich Internet Application (RIA) written in the JavaScript language and a web service written in the Java language, which objects may be represented in the JavaScript Object Notation (JSON) format (trademarks); the Java language has a richer set of types than the JavaScript language has, so that it may be not possible to de-serialize a JSON representation of a JavaScript object into a Java object perfectly mapping it.
In order to tackle this problem, a custom converter is usually added to the target software component; the converter comprises code specifically written for handling the de-serialization of the representations of the source objects into corresponding target objects—for example, as described in US-A-2010/0083277 (the entire disclosure of which is herein incorporated by reference) for de-serializing incoming request messages in a SOA framework into Java objects.
However, this increases the development cost of the target software component. Moreover, the maintenance of the converter is quite difficult, since it requires working on two layers to maintain the converter in the target software component synchronized with the source software component. This process is time-consuming (thereby further increasing the development cost of the target software component) and prone to errors (thereby adversely affecting the quality of the target software component). The problem is particular acute when the source objects have a complex structure (for example, a list of items of different types, a list of nested lists, and the like).
Alternatively, US-A-2011/0321010 (the entire disclosure of which is herein incorporated by reference) mentions the possibility of using a new format, which allows specifying the type of each source object and its fields. However, the use of this format would require a corresponding parser that is not described in the cited document (and it does not have any reference implementation). Moreover, metadata modeling each source object would be required both in the definitions of the source objects (in the new format) and in the target software component; this involves the replication of information with detrimental effects on its maintenance. At the end, the possibility mentioned in the cited document would require the learning of a new language (different from the ones commonly known at the moment).